Fix empty fields in first hypervisor log line

Instead of:

    (XEN) Xen version 4.11.1 (Debian )
    (@)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 19:08:37 UTC 2019

I'd like to see:

    (XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
    (pkg-xen-devel@lists.alioth.debian.org)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 22:44:00 CET 2019

The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.

Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.

Revert "tools-xenstore-compatibility.diff"

Following recent discussion in pkg-xen-devel and xen-devel,
  https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg00838.html
I am dropping this patch.

For now I revert it.  When we next debrebase, we can (if we like)
throw away both the original patch, and this revert.

This reverts commit 5047884c76849b67e364bc525d1b3b55e781cf16.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/firmware/Makefile: CONFIG_PV_SHIM: enable only on x86_64

Previously this was *dis*abled for x86_*32*.  But if someone should
run some of this Makefile on ARM, say, it ought not to be built
either.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

tools/firmware/Makfile: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

Patch-Name: tools-libfsimage-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name tools-libfsimage-prefix.diff

tools-libfsimage-abiname.diff

Patch-Name: tools-libfsimage-abiname.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name tools-libfsimage-abiname.diff

Do not build the instruction emulator

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
  https://wiki.debian.org/Hardening/PIEByDefaultTransition

This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only.  So pass
options to disable this.

These options will be no-ops if they are the same as the compiler
default.

On amd64, the -fno-pic breaks the build in a different way.  So do
this only on i386.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

tools-xenmon-install.diff

Patch-Name: tools-xenmon-install.diff

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-xenmon-install.diff

Do not ship COPYING into /usr/include

This is not wanted in Debian.  COPYING ends up in
/usr/share/doc/xen-*copyright.

Patch-Name: tools-include-no-COPYING.diff

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name config-prefix.diff

version

Patch-Name: version.diff

Gbp-Pq: Topic misc
Gbp-Pq: Name version.diff

tools/kdd: mute spurious gcc warning

gcc-8 complains:

    kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds [0, 216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union <anonymous>'} [-Werror=array-bounds]
                 memcpy(buf, ((uint8_t *)&ctrl.c32) + offset, len);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    kdd.c: In function 'kdd_select_callback':
    kdd.c:642:14: note: 'ctrl' declared here
         kdd_ctrl ctrl;
                  ^~~~

But this is impossible - 'offset' is unsigned and correctly validated
few lines before.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 437e00fea04becc91c1b6bc1c0baa636b067a5cc)

libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2

Add zero-padding to #defined ACPI table strings that are copied.
Provides sufficient characters to satisfy the length required to
fully populate the destination and prevent array-bounds warnings.
Add BUILD_BUG_ON sizeof checks for compile-time length checking.

Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit b8f33431f3dd23fb43a879f4bdb4283fdc9465ad)

tools: Move ARRAY_SIZE() into xen-tools/libs.h

xen-tools/libs.h currently contains a shared BUILD_BUG_ON() implementation and
is used by some tools.  Extend this to include ARRAY_SIZE and clean up all the
opencoding.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit e1b7eb92d3ec6ce3ca68cffb36a148eb59f59613)

xenpmd: make 32 bit gcc 8.1 non-debug build work

32 bit gcc 8.1 non-debug build yields:

xenpmd.c:354:23: error: '%02x' directive output may be truncated writing between 2 and 8 bytes into a region of size 3 [-Werror=format-truncation=]
     snprintf(val, 3, "%02x",
                       ^~~~
xenpmd.c:354:22: note: directive argument in the range [40, 2147483778]
     snprintf(val, 3, "%02x",
                      ^~~~~~
xenpmd.c:354:5: note: 'snprintf' output between 3 and 9 bytes into a destination of size 3
     snprintf(val, 3, "%02x",
     ^~~~~~~~~~~~~~~~~~~~~~~~
              (unsigned int)(9*4 +
              ~~~~~~~~~~~~~~~~~~~~
                             strlen(info->model_number) +
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                             strlen(info->serial_number) +
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                             strlen(info->battery_type) +
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                             strlen(info->oem_info) + 4));
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All info->* used in calculation are 32 bytes long, and the parsing
code makes sure they are null-terminated, so the end result of the
expression won't exceed 255, which should be able to be fit into 3
bytes in hexadecimal format.

Add an assertion to make gcc happy.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit e75c9dc85fdeeeda0b98d8cd8d784e0508c3ffb8)

Delete configure output

These autogenerated files are not useful in Debian; dh_autoreconf will
regenerate them.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Delete config.sub and config.guess

dh_autoreconf will provide these back.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-xenstore-compatibility.diff

Patch-Name: tools-xenstore-compatibility.diff

Gbp-Pq: Topic xenstore
Gbp-Pq: Name tools-xenstore-compatibility.diff

tools-fake-xs-restrict

Gbp-Pq: Topic xenstore
Gbp-Pq: Name tools-fake-xs-restrict.patch

tools/debugger/kdd: Install as `xen-kdd', not just `kdd'

`kdd' is an unfortunate namespace landgrab.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xenmon: Install as xenmon, not xenmon.py

Adding the implementation language as a suffix to a program name is
poor practice.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub fsimage.so: Honour LDFLAGS when building

This seems to have been simply omitted.  Obviously this is needed when
building and not just when installing.  Passing only when installing
is ineffective.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

libfsimage: Honour general LDFLAGS

Do not reset LDFLAGS to empty.  Instead, append the fsimage-special
LDFLAGS.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

gdbsx: Honour LDFLAGS when linking

This command does the link, so it needs LDFLAGS.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/xenstat: Fix shared library version

libxenstat does not have a stable ABI.  Set its version to the current
Xen release version.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

docs/man/xen-pv-channel.pod.7: Remove a spurious blank line

No functional change.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

docs/man: Provide properly-formatted NAME sections

A manpage `foo.7.pod' must start with

  =head NAME

  foo - some summary of what foo is or what this manpage is

because otherwise manpage catalogue systems cannot generate a proper
`whatis' entry.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

INSTALL: Mention kconfig

Firstly, add a reference to the documentation for the kconfig system.

Secondly, warn the user about the XEN_CONFIG_EXPERT problem.

CC: Doug Goldstein <cardoe@cardoe.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/Rules.mk: Honour PREPEND_LDFLAGS_XEN_TOOLS

This allows the caller to provide some LDFLAGS to the Xen build
system.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/xentop : replace use of deprecated vwprintw

gcc-8.1 complains:

| xentop.c: In function 'print':
| xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations]
|     vwprintw(stdscr, (curses_str_t)fmt, args);
|     ^~~~~~~~

vw_printw (note the underscore) is a non-deprecated alternative.

Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name tools-xentop-replace-use-of-deprecated-vwprintw.patch

Various: Fix typo `mappping'

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Various: Fix typo `infomation'

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/python/xen/lowlevel: Fix typo `sucess'

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Various: Fix typo `reseting'

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Various: Fix typo `occured'

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Various: Fix typos `unkown', `retreive' (detected by lintian)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/xentrace/xenalyze: Fix typos detected by lintian

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

docs/man: Fix two typos detected by the Debian lintian tool

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

/etc/default/xen: Handle with ucf

We reintroduced this file in
  "d/xen-utils-common.install: ship /etc/default/xen"
  eg 2f34db35dd27abb4280d38ebc4464c21f64df8c9

But I had forgotten that this file was previously shipped and handled
by ucf; and we have machinery to try to remove it.

This leaves the following possible cases:
(a) stretch: file handled by ucf
(b) older buster: file not shipped, ucf postinst action not done
   | file remains recorded by ucf and ucfr, but that the original
   | version of the file is no longer present on the user's machine
(c) newer buster: file shipped, file recorded by ucf with one
   old version and as dpkg conffile by newer version

(a) and (b) will be handled correctly by just using ucf in the normal
way.

(c) xxx needs testing

So:
 * Drop the special call to ucf-remove-fixup; retain the call to ucf
 * Switch to shipping the file in /usr/share as expected by ucf

We do not remove the file's entry from not-installed - see the
comment relating to #831786.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: start 3~

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: debian part]

d/not-installed: work around dh-exec bug

dh-exec breaks dh_missing by failing to register the installed files.
Put a workaround in place.

Closes: #923013
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/[..]/grub.d/xen.cfg: dom0_mem max IS needed

I misread the upstream documentation. Adding max: for x86 is actually
necessary to not have it "attempt to allocate enough page tables to
cover all of *host* RAM which can exhaust its actual memory allocation".

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

changelog: finalise -2

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Packaging change: override lintian warning about fsimage.so rpath.

This warning is spurious.  Normally .debs should not set rpath but in
this case it is needed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: start -2~

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: finalise for release to sid/buster

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: Remove a trailing space

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: manually edit, preparatory to release

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: gbp dch --ignore-branch --since=a8ba67214681b6c5a5d7486550585116f1690ed0

On top of bd06240ecc, which was before the gdr new-upstream
The --since is the last edit to d/changelog

(Cherry picked onto my current master, dealing with conflicts.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Update changelog for new upstream 4.11.1+26-g87f51bf366

[git-debrebase changelog: new upstream 4.11.1+26-g87f51bf366]

Update to upstream 4.11.1+26-g87f51bf366

[git-debrebase anchor: new upstream 4.11.1+26-g87f51bf366, merge]

xencommons xenstored startup: Use --pid-file $F not --pid-file=$F

The ocaml libraries in stretch understands only the variant
with separate arguments.  So a build of this package for stretch
produces an error message and C xenstored instead of oxenstored.

Fix this here even in the buster branch since it makes backporting
easier.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xendomains init script; Add should-dependency on nfs-kernel-server

Perhaps the guests use the hosts's NFS server, as in the case reported
in #826871.

In any case, it seems much more likely that on a system which is an
NFS server and also a Xen host, that the guests depend on the NFS,
rather than vice versa.

The obvious exception would be a driver domain.  Driver domains
probably need to be handled separately anyway, since they must start
before other domains.  (And anyway they are not particularly
well-handled by the current packaging.)

Closes: #826871
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xendomains init script; Add dependency on $network

xendomains generally needs to start after the bridge is set up.

In
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798510#20
it was reported that for that user this improves things.

We expect that this change may help with (or at least mask) some other
starup races such as that in the original report for #798510.

Closes: #798510
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

hotplug-common: Strip arch-specific libdir from config file

Closes: #862236
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Fix tiny typo

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xen init script: don't fail when being run in domU

When installing xen-utils-V in a driver domain domU, it drags in
xen-utils-common, which also contains the init script for xenstored and
xenconsoled.

Installing the package will fail right away, because it exits non-zero
after checking whether it's running in a xen dom0 or not:

 systemd[1]: Starting LSB: Xen daemons...
 xen[7215]: Starting Xen daemons: (warning).
 systemd[1]: xen.service: Control process exited, code=exited, status=255/EXCEPTION
 systemd[1]: xen.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start LSB: Xen daemons.
 dpkg: error processing package xen-utils-common (--configure):
  installed xen-utils-common package post-installation script subprocess returned error exit status 1

Since there's nothing to be fixed, there should not be a warning. It's
totally fine to skip xenstored, xenconsoled and qemu steps in this case,
so just exit cleanly.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/[..]/grub.d/xen.cfg: improve docs even more

Ok, I finally tried this, and it's really great that I now have correct
(different) linux kernel options generated for just linux and xen+dom0.

Do more cosmetics and reorganizing to make this wall of comments better
parseable by the eye. It was not obvious to me where sections started
and ended, and I like to have first the explanation and then at the end
the actual variables you can set.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/x-u-common.install: install completion as as xl

...and not as xl.sh. All other files in that completions directory also
don't have .sh. This is just cosmetics, but it annoys me. And we have
dh-exec in here now anyway. :]

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: move init_dom0 into xenstored start

Executing this is only necessary after starting xenstored. In all other
cases it just prints noop spam to stderr.

    -# /usr/lib/xen-4.11/bin/xen-init-dom0 >/dev/null
    Dom0 is already set up

I don't want to silence stderr, so just move the code into the end of
the xenstored start function.

Also, add a hint that the compatibility if/else part should be removed
after the Buster release.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

xen init script: rewrite xenstored start logic

We're adding oxenstored, and we want use it by default in Xen 4.11.

When doing a Debian upgrade from Stretch to Buster, the xen-utils-common
package will be upgraded to the new version, but it still needs to
support running the Xen 4.8 hypervisor and utils, because the user might
not have rebooted yet, or might boot into the 4.8 hypervisor again
because there were troubles running 4.11.

So, this means that oxenstored might or might not be available, and we
have to deal with that.

See comments in the code for more explanation about the new program
flow.

Also...
* Allow the user to explicitly configure a xenstored binary in
/etc/default/xen.
* Use if statements rather than constructs using || and && to make the
program flow a bit easier to understand.
* Remove the confuscating madness of having 1 as a success return code.
* Don't print the xenstored progress message if we're not touching it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/xen-utils-common.install: ship /etc/default/xen

This file has been in the package before, it contained TOOLSTACK= to
switch between xm and xl. It was abandoned and never cleaned up, so old
installs still have this file.

Ship it again.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

oxenstored: Build it

 * Add the relevant build dependencies

     ocaml-native-compilers is good on stretch because it
     will get us better output code.  In buster the
     ocaml-native-compilers package is merged into ocaml-nox.
     In bullseye we can drop ocaml-native-compilers from the list.

 * Drop the rules line that disables the ocaml build.

 * Ship /etc/xen/oxenstored.conf.

 * Placate dh_missing about ocaml development libraries.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
[add trailing comma, fix typo, change bulleseye line]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: Tidy up wrong/missing Xen version error handling

We no longer want to discard the stderr from xen-dir, and treat this
as a success.  All the reasons why this failure might previously have
been thought tolerable have been dealt with.

Specifically, we will no longer reach this code if we are not running
under Xen, or if we ran this init script on behalf of a xen-utils-V
package for some V different to the running Xen version.

We know we are running under Xen, and that either we're running not as
a result of a maint script, or as a result of a xen-utils-V maint
script for the running Xen version, or as a result of some other maint
script (of which we don't think there are any, but it presumably
expects this code to work).

So if xen-dir fails, let it print its error message, and also exit
nonzero.  And don't mention not running under Xen in our
log_warning_msg.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: Do nothing if running for wrong Xen package

See the big comment.  We think that this is responsible for various
bugs and, particularly, reports of mysteriously missing xenconsoled.

For example, this bug would mean that after a Xen version upgrade,
autoremoval of an obsolete xen-utils-V package would stop the running
xenconsoled.  This is obviously awkward to track down, and could occur
many weeks or months after the upgrade.

Closes: #851654
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: silently exit status 0 if not running under xen

This script should not complain at all if we are not running under
Xen.  Check this right at the start.

This will enable improvements to the following code, which will no
longer have to deal with the `not running under Xen' case.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen version/upgrade handling: Improve an error message

When xen-dir cannot find xen-utils, mention that this might be because
xen-utils-<RUNNING-XEN-VERSION> was already removed.

This is generally helpful, but it does not solve the `missing
xenconsoled' problems because 1. it only changes messages and
2. actually in the init script, the error message is currently
discarded anyway (!)

But, anyway, it is an improvemennt.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

debian/.gitignore: ignore more debhelper snippets

Stuff like:

debian/xen-utils-common.preinst.debhelper
debian/xen-utils-common.prerm.debhelper

debian/xen-utils-common.*: remove more xend cruft

Ah, these files are still present on my dom0, while they're obsolete and
not shipped any more. Have them removed, so that they don't confuse the
user.

(Someone might run into old documentation about xend and see that the
files are there, and try setting options, which don't do anything
etc...)

Unpacking xen-utils-common (4.11.1-2~) over (4.11.1-2~) ...
Setting up xen-utils-common (4.11.1-2~) ...
Obsolete conffile /etc/default/xend has been modified by you.
Saving as /etc/default/xend.dpkg-bak ...
Removing obsolete conffile /etc/xen/xend-config.sxp ...
Removing obsolete conffile /etc/xen/xend-pci-permissive.sxp ...
Removing obsolete conffile /etc/xen/xend-pci-quirks.sxp ...
[...]

debian/control: bump debhelper builddep to 10

The debian/compat file contains '10', so make sure that there's actually
a debhelper being dragged in that can do everything needed.

This fixes the lintian warning:
    package-needs-versioned-debhelper-build-depends

d/xen-utils-V...: override xen-shim-syms lintian

This is ok, it's not a file that is meant to be executed on the host
system itself.

debian/control: add dh-python build-dep

Lintian is complaining: missing-build-dependency-for-dh_-command

"The source package appears to be using a dh_ command but doesn't build
depend on the package that actually provides it. If it uses it, it must
build depend on it."

debian/libxenstore3.0.symbols: revert ea2334dfe0

This part of commit ea2334dfe0 was left behind after redoing the
packaging and getting all libraries in the right place. The build now
complains about it:

dpkg-gensymbols: warning: some libraries disappeared in the symbols
file: libxentoolcore-4.10.so.1

dpkg-gensymbols: warning: debian/libxenstore3.0/DEBIAN/symbols doesn't
match completely debian/libxenstore3.0.symbols

debian/xen-utils-common.*: remove xend cruft

xend is obsolete and removed. Still, there are some traces of it in init
and other scripts. Remove all of it now.

Also remove a migration step about upgrading to 4.1, since we don't
support directly upgrading from something older than that to the current
package.

d/control: xenstore-utils breaks xen-utils-common

In the theoretical case that xenstore-utils gets upgraded, when
upgrading from Stretch to Buster, and then deliberately gets downgraded
again by the user, a few manual page files could be removed.

In a normal sane upgrade scenario this would never happen.

d/control: have xen-utils-common suggest xen-doc

d/[..]/grub.d/xen.cfg: command line "starter kit"

As pointed out by Gergely in debian bug #919758, the examples in the
grub documentation contain incorrect suggestions, at least for dom0_mem
and earlyprintk.

Correct those, and take the opportunity to refresh all of this a bit,
including the most common set of used options.

Also, point to the online documentation where more explanation about all
options can be found.

(Closes: #919758)

changelog: start an empty changelog for 4.11.1-2~

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

finalise 4.11.1-1

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

d/changelog: mention further changes done

d/changelog: Add CVE numbers for recent XSAs

d/changelog: lower unreleased version

When building some intermediate packages and installing with dpkg -i, I
still want to be able to 'normally' upgrade with apt to the final
version.

d/changelog: mention XSA fixes

libxl: correctly dispose of dominfo list in libxl_name_to_domid

Tamas reported ssid_label was leaked. Use the designated function to
free dominfo list to fix the leakage.

Reported-by: Tamas K Lengyel <tamas@tklengyel.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit f50dd67950ca9d5a517501af10de7c8d88d1a188)

libxl: don't set gnttab limits in soft reset case

In case of soft reset the gnttab limit setting will fail, so omit it.
Setting of max vcpu count is pointless in this case, too, so we can
drop that as well.

Without this patch soft reset will fail with:

libxl: error: libxl_dom.c:363:libxl__build_pre: Couldn't set grant table limits

Reported-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>

correct release note link in SUPPORT.md

The syntax for the release note link in SUPPORT.md is wrong. Correct
that.

Signed-off-by: Juergen Gross <jgross@suse.com>

x86/hvm: Fix bit checking for CR4 and MSR_EFER

Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest.  Auditing against the host CPUID was better than nothing, but not
ideal.

Similarly at the time, PVHv1 lacked the "CPUID passed through from hardware"
behaviour with PV guests had, and PVH dom0 had to be special-cased to be able
to boot.

Order of information in the migration stream is still an issue (hence we still
need to keep the restore parameter to cope with a nested virt corner case for
%cr4), but since Xen 4.9, all domains start with a suitable CPUID policy,
which is a more appropriate upper bound than host_cpuid_policy.

Finally, reposition the UMIP logic as it is the only row out of order.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
master commit: 9d8c1d1814b744d0fb41085463db5d8ae025607e
master date: 2019-01-29 11:28:11 +0000

x86/AMD: flush TLB after ucode update

The increased number of messages (spec_ctrl.c:print_details()) within a
certain time window made me notice some slowness of boot time screen
output. Experimentally I've narrowed the time window to be from
immediately after the early ucode update on the BSP to the PAT write in
cpu_init(), which upon further investigation has an effect because of
the full TLB flush that's implied by that write.

For that reason, as a workaround, flush the TLB of the mapping of the
page that holds the blob. Note that flushing just a single page is
sufficient: As per verify_patch_size() patch size can't exceed 4k, and
the way xmalloc() works the blob can't be crossing a page boundary.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Brian Woods <brian.woods@amd.com>
master commit: f19a199281a23725beb73bef61eb8964d8e225ce
master date: 2019-01-28 17:40:39 +0100

xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct

When the command line parsing was updated to use const strings and no longer
tokenise with NUL characters, string matches could no longer be made with
strcmp().

Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
"o", "op" and "opt" on the command line, as ss - s may be shorter than the
passed literal.  Furthermore, parse_bool() is affected by this, so substrings
such as "d", "e" and "o" are considered valid, with the latter being ambiguous
between "on" and "off".

Introduce a new strcmp-like function for the task, which looks for exact
string matches, but declares success when the NUL of the literal matches a
comma, colon or semicolon in the command line fragment.

No change to the intended parsing functionality, but fixes cases where a
partial string on the command line will inadvertently trigger options.

A few areas were more than just a trivial change:

 * parse_irq_vector_map_param() gained some style corrections.
 * parse_vpmu_params() was rewritten to use the normal list-of-options form,
   rather than just fixing up parse_vpmu_param() and leaving the parsing being
   hard to follow.
 * Instead of making the trivial fix of adding an explicit length check in
   parse_bool(), use the length to select which token to we search for, which
   is more efficient than the previous linear search over all possible tokens.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
master commit: 2ddf7e3e341df3ccf21613ff7ffd4b7693abe9e9
master date: 2019-01-15 12:58:34 +0000

mm/page_alloc: fix MEMF_no_dma allocations for single NUMA

Currently dma_bitsize is zero by default on single NUMA node machines.
This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.

There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
during memory allocation for Dom0. Failing allocation with default
dom0_memflags is especially severe for the PV Dom0 case: it makes
alloc_chunk() to use suboptimal 2MB allocation algorithm with a search
for higher memory addresses.

This can lead to the NMI watchdog timeout during PV Dom0 construction
on some machines, which can be worked around by specifying "dma_bits"
in Xen's cmdline manually.

Fix the issue by ignoring MEMF_no_dma in cases when dma_bitsize is zero,
which means there is no DMA zone. This shouldn't cause any issues for
Dom0 because alloc_heap_pages() will first use higher memory addresses
for satisfying memory allocation requests.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5ac2dddb173b69be259ce4b259e73f971a4816c1
master date: 2019-01-09 15:45:14 +0100

x86emul: work around SandyBridge errata

There are a number of exception condition related errata on SandyBridge
CPUs, some of which are unexpected #UD (others, of no interest here, are
lack of mandated exceptions, or exceptions of unexpected type). Annotate
the one workaround we already have, and add two more.

Due to the exception recovery we have in place for stub invocations
these aren't security issues.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 0d4d9e8f55602415475e04a5dc8b4ad27845a7f9
master date: 2018-12-18 15:19:47 +0100

x86emul: fix 3-operand IMUL

While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
as its title says, it broke the 3-operand form by uniformly using AL/AX/
EAX/RAX as second source operand. Fix this and add tests covering both
cases.

Reported-by: Andrei Lutas <vlutas@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
master date: 2018-12-18 14:27:09 +0100

x86/hvm: Corrections to RDTSCP intercept handling

For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
supports the instruction, but the guest may not have RDTSCP in its featureset.
Bring the vmexit handlers in line with the main emulator behaviour by
optionally handing back #UD.

Next on the AMD side, if RDTSCP actually ends up being intercepted on a debug
build or first-gen SVM hardware which lacks NRIP, we first update regs->rcx,
then call __get_instruction_length() asking for RDTSC.  As the two
instructions are different (and indeed, different lengths!),
__get_instruction_length_from_list() fails and hands back a #GP fault.

This can demonstrated by putting a guest into tsc_mode="always emulate" and
executing an RDTSCP instruction:

  (d1) --- Xen Test Framework ---
  (d1) Environment: HVM 64bit (Long mode 4 levels)
  (d1) Test rdtscp
  (d1) TSC mode 1
  (XEN) emulate.c:147:d1v0 __get_instruction_length: Mismatch between expected and actual instruction:
  (XEN) emulate.c:152:d1v0   insn_index 8, opcode 0xf0031 modrm 0
  (XEN) emulate.c:154:d1v0   rip 0x10475f, nextrip 0x104762, len 3
  (XEN) SVM insn len emulation failed (1): d1v0 64bit @ 0008:0010475f -> 0f 01 f9 0f 31 5b 31 ff 31 c0 e9 c2 db ff ff 00
  (d1) ******************************
  (d1) PANIC: Unhandled exception at 0008:000000000010475f
  (d1) Vec 13 #GP[0000]
  (d1) ******************************

First, teach __get_instruction_length() to cope with RDTSCP, and improve
svm_vmexit_do_rdtsc() to ask for the correct instruction.  Move the regs->rcx
adjustment into this function to ensure it gets done after we are done
potentially raising faults.

Reported-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Brian Woods <brian.woods@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 3fd3fda9c26fc3c4f77250f795ed7ff9d38e2ec6
master date: 2018-12-17 16:28:03 +0000